Bug: Missing else causes reject after successful resolve

The exit handler unconditionally calls reject() after conditionally calling resolve() for zero exit codes. When exitCode === 0, both resolve('success (live mode)') and reject(new Error(...)) execute sequentially. While promises only settle once, this creates an unhandled rejection and indicates incorrect control flow logic. An else clause or return statement is needed to prevent rejection after successful resolution.

@szokeasaurusrex Here the live option is entirely removed, but in types.ts the live option is just adapted. What is now true?

Yes, exactly, this removal is intentional. For sourcemaps upload, we always use live = true, and there is no way to override this (this is actually what we had prior to introducing the 'rejectOnError' option; we only made live configurable here to allow us to use 'rejectOnError').

Bug: The pid.on('exit') handler unconditionally calls reject() after resolving when exitCode === 0, causing promises to always fail.
_{Severity: CRITICAL | Confidence: High}

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: lib/helper.js#L335-L338

Potential issue: The `pid.on('exit')` handler in `lib/helper.js` lines 335-338 contains
a logic error. When `exitCode === 0`, the promise correctly resolves with `'success
(live mode)'`. However, the `reject()` statement immediately follows this `if` block and
is not enclosed in an `else` block, causing it to execute unconditionally. This means
that even on successful process execution (`exitCode === 0`), the promise will first
resolve and then immediately reject. This behavior causes `Promise.all()` calls, such as
in `uploadSourceMaps()` in `lib/releases/index.js`, to fail entirely, as each individual
promise will ultimately reject.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 5120123}